title: git文档8 - 自定义 Git
date: 2020.11.15
top:

categories:

tags:

• git
  toc_fold: unfold

8. 自定义 Git

8.1 配置 Git
8.2 Git 属性
8.3 Git 钩子
8.4 使用强制策略的一个例子
8.5 总结

2020.11.15 星期日 23：36

8.1 配置 Git

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
它首先会查找系统级的 /etc/gitconfig 文件，该文件含有系统里每位用户及他们所拥有的仓库的配置值。 如果你传递 --system 选项给 git config，它就会读写该文件。
接下来 Git 会查找每个用户的 ~/.gitconfig 文件（或者 ~/.config/git/config 文件）。 你可以传递 --global 选项让 Git 读写该文件。
最后 Git 会查找你正在操作的仓库所对应的 Git 目录下的配置文件（.git/config）。 这个文件中的值只对该仓库有效，它对应于向 git config 传递 --local 选项。

以上三个层次中每层的配置（系统、全局、本地）都会覆盖掉上一层次的配置，所以 .git/config 中的值会覆盖掉 /etc/gitconfig 中所对应的值。

客户端基本配置

man git-config

git config --global core.editor emacs
git config --global commit.template ~/.gitmessage.txt

git config --global core.pager ''
git config --global user.signingkey <gpg-key-id>
git config --global core.excludesfile ~/.gitignore_global
# help.autocorrect 接受一个代表十分之一秒的整数。 所以如果你把它设置为 50, Git 将在自动执行命令前给你 5 秒的时间改变主意。

Git 中的着色

color.ui
color.*

git config --global color.ui false
git config --global color.diff.meta "blue black bold"

外部的合并与比较工具

这里我们以一个不错且免费的工具 —— Perforce 图形化合并工具（P4Merge）

git mergetool，Git 会调用 P4Merge 让你通过图形界面来解决冲突。
Git 预设了许多其他的合并和解决冲突的工具，无需特别的设置你就能用上它们。 要想看到它支持的工具列表，
git mergetool --tool-help
git config --global merge.tool kdiff3

$_PS: 略。编辑器亦可。

格式化与多余的空白字符

core.autocrlf
core.whitespace

服务器端配置

receive.fsckObjects

receive.denyNonFastForwards

receive.denyDeletes

8.2 Git 属性

你也可以针对特定的路径配置某些设置项，这样 Git 就只对特定的子目录或子文件集运用它们。 这些基于路径的设置项被称为 Git 属性，
可以在你的目录下的 .gitattributes 文件内进行设置（通常是你的项目的根目录）。
如果不想让这些属性文件与其它文件一同提交，你也可以在 .git/info/attributes 文件中进行设置。

通过使用属性，你可以对项目中的文件或目录单独定义不同的合并策略，让 Git 知道怎样比较非文本文件，或者让 Git 在提交或检出前过滤内容。

二进制文件

识别二进制文件
*.pbxproj binary

比较二进制文件

*.docx diff=word
所有匹配 .docx 模式的文件都应该使用“word”过滤器。
借助 docx2txt 程序将 Word 文档转为可读文本文件，这样不同的文件间就能够正确比较了。
git config diff.word.textconv docx2txt

还能用这个方法比较图像文件。
运用一个过滤器，提炼出 EXIF 信息. … 下载并安装了 exiftool 程序，
*.png diff=exif
git config diff.exif.textconv exiftool

关键字展开

*.txt ident

不过，我们可以在检出某个文件后对其注入文本，并在再次提交前删除这些文本。 Git 属性提供了两种方法来达到这一目的。
一种方法是，你可以把文件所对应数据对象的 SHA-1 校验和自动注入到文件中的 $Id$ 字段。
另一种方法：我们可以编写自己的过滤器来实现文件提交或检出时的关键字替换。 一个过滤器由“clean”和“smudge”两个子过滤器组成。
*.c filter=indent
git config --global filter.indent.clean indent
git config --global filter.indent.smudge cat

$_PS: 功能是强大。不用

导出版本库

export-ignore
test/ export-ignore
当你运行 git archive 来创建项目的压缩包时，那个目录不会被包括在归档中。

export-subst
在导出文件进行部署的时候，你可以将 git log 的格式化和关键字展开处理应用到标记了 export-subst 属性的部分文件。
LAST_COMMIT export-subst

echo 'Last commit date: $Format:%cd by %aN$' > LAST_COMMIT
git add LAST_COMMIT .gitattributes
git commit -am 'adding LAST_COMMIT file for archives'
## 运行 git archive 之后，归档文件的内容会被替换成这样：
git archive HEAD | tar xCf ../deployment-testing -
cat ../deployment-testing/LAST_COMMIT
Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon

你也可以用诸如提交信息或者任意的 git notes 进行替换，并且 git log 还能做简单的字词折行：

echo '$Format:Last commit: %h by %aN at %cd%n%+w(76,6,9)%B$' > LAST_COMMIT
git commit -am 'export-subst uses git log'\''s custom formatter

由此得到的归档适用于（当前的）部署工作。然而和其他的导出归档一样，它并不适用于后继的部署工作。

$_PS: 最后一个看了个寂寞。

合并策略

database.xml merge=ours
git config --global merge.ours.driver true

$_PS: gitattribute先后顺序很重要！！

<!– 原来gitattribute方法生效是有条件的，跟文件的修改顺序有关系，只有先修改的往后来修改的合并的时候才会生效。
这里的先后是指文件的最后修改时间，不是创建的时间，如果最近修改过，那它就是最新的，
比如刚才的例子，我们修改了publish分支的info.plist，而没有对另外两个分支下的info.plist进行修改，那么publish分支下的info.plist就比另外两个分支新，
这时候合并的时候，gitattribute就会失去作用，那么该如做呢，我们在修改完publish分支后，需要再次修改另外两个分支下的plist配置文件，即使没啥可以改的，也要改(可以先改错，再改回去)这样我们publish分支下的，就会仍然保持最旧。

举例：
release和debug都有个配置项文件：config
如果合并时你要忽略config，那你要先改debug分支的config，然后再改release分支的config，
这样你在release分支下进行：git merge debug时就会忽略config文件。
–>

8.3 Git 钩子

有两组这样的钩子：客户端的和服务器端的。

安装一个钩子

客户端钩子

客户端钩子分为很多种。 下面把它们分为：提交工作流钩子、电子邮件工作流钩子和其它钩子。

提交工作流钩子

pre-commit
prepare-commit-msg
commit-msg
post-commit

电子邮件工作流钩子

你可以给电子邮件工作流设置三个客户端钩子。
它们都是由 git am 命令调用的，因此如果你没有在你的工作流中用到这个命令，可以跳到下一节。
如果你需要通过电子邮件接收由 git format-patch 产生的补丁，这些钩子也许用得上。

applypatch-msg
pre-applypatch
post-applypatch

其它客户端钩子

pre-rebase
post-rewrite
post-checkout
post-merge
pre-push
pre-auto-gc

服务器端钩子

pre-receive
update
post-receive

$_PS: husky常用到的，提交前lint代码，检测提交规范；
$_PS: CI/CD 用到，push/tag后触发构建；PR后介绍邮件

8.4 使用强制策略的一个例子

建立这样一个 Git 工作流程：检查提交信息的格式，并且指定只能由特定用户修改项目中特定的子目录。
你将编写一个客户端脚本来提示开发人员他们的推送是否会被拒绝，以及一个服务器端脚本来实际执行这些策略。

$_PS: 略。没有看明白

服务器端钩子
指定特殊的提交信息格式
指定基于用户的访问权限控制列表（ACL）系统
测试一下
客户端钩子

###

###

###

###

8.5 总结